#@L}5 _$% l0$)$$Hȱ$ UhL" `e$$%`$%`  R@W!( L(1   Y I`  d  Ld M * @  $ % CC$$)%1 Udߥ$9%: !0 S$% DD˙`  }J)Lr d M * @  $ % CC$$)%1 Udߥ$9%: !0 S$%} DD˙`  }J)Lr J  ((  p L ()   J}L= ( L 0q A    IB JC;? D W } LL  ` W )LA!  ߰")-݆ p" } $G@LL 08`Q")<2Q0 -G$Ș݆ UL# ; p8(()(0ʥ)NQ` }$GȘ݆LU )L ݆ L GȘ ݆LL )W>Z   HH)H }p h  hyhy D L> L JJ    ! LA*` BF }7'8  M HN H` 8 Z  \LdJJ!"! GFE@F (!L }EE !E^ ^ E E7EȩEdE/EȩE  D } .L }  ;F d  ;?F7F? ( .   Z D LL d } . D  L    p  E` , d)  D L) 0BM݊L݉} ML  N݆ L NLML [ TEqEHȱEqEh 0Gȹ G} HLL GɛL  LFREE SECTORS G) *Gȩ GȽG GȌ*jj >G} C8jJ3j2CD( C202C ԠBX` N 1? l LlD:RAMDISK}.COMLu L1 L ;LHL  T`  `1  ɐ     `TU  } L ? .  t`GBJ ~DEHI B V0dV!}QDEHI VF9 ,0 ,0 s0hhL  L` H hDHEh"}DEL8HI4 0 HI,0 0  9 .G VLO#},0 L4*IJ`llD1:AUTORUN.SYSNEED MEM.SAV TO LOAD THIS FILE.D1:MEM.SAV J y08 B|DEHI$} V0 0`B;DEL`?<0LV`@ʆ v s? F0Ξ05: [ BDEHI%} VY8 B V  @  /DE `E:D1:DUP.SYSERROR-SAVING USER MEMORY ON DISKTYPE Y TO &}STILL RUN DOS B;DE J  (` 9 V⪍ ઍ  -'}LLu ÝDEHILV 9 .l 9 .l  `` s$B BH(}I|DE V BLV nB,DE JLV B V BLVDEIʩ BꭝLu }M D D D D %BB! % 9* v% w%u % D %LJ& fffffff>`<*}|0`̌8l8pv00````00 0f< x||||-}|||~|l8l8lfff< 0`@`0 000006c!"|™.}|™|~x|™|as22sa>2222r|晒xLLLLNB|晁晉|™||™/}v|~Þ~fdddd||晙d8晙™晙dd|2x`x`~<~~<"#30 ~ <~~<0}|~~||~~||>````~~8<8<||1}~~~|0000~l8|ll8l~ 8`8pp##82}$ %0$1$3$4$ ?̏?1$4$ॄ``ex$w$e{$z$褄 x${3}$`(mDeXYi????)^̜D)DȄ?Čei?̜D@L$4}i( %&L$??`??????8??Ƌ拑` T8` 8` n%D5} %LJ&} T8t?????@:@CD(DDi?18?8?8?@K????` -??6} $ &= Y%&'?L' &= Y%?`'XRUT`H)h)` i@LG&8 `DCIDID $ 87}Х)LS&ЭC?H &hɛL&,C0ɜf) `{\\X^T_PHC^? e,h .&) C8} $8??''i?i? 'LJ&?'?'LJ&ʊ &HIHd'Hc'H`# \^_|}~2k)9}9:+O)29+,0];'3A/1/s)l32'))(m(( ):--,+<,+4,++d,CIC`"I"` (8??8??? ??:} $8?内?凅((?m???i? $L'`8???? ????8?? ??`8??;}`??`ЭD(DDΝD $ '} T8L &L'ЭDΜDΜDD $ '} T8L &ƇƆL'<}Ƌ^^()`8eiL'^` 懥͒?^eiL'??L'=}??8̓??? $LC)s)s)`)))))`Ƌ ^`^Ƌ͂?L)ƌ >}L(L)??L')*^懥͒?LC)懥͒?LC)^L4)??????}`8??hh``8Ie?Ie?????8?m?͉? &۠= Y%?`???m?@}??m?? $????8?傅*+?僅 $8??????` K* ( h*8????` n( K* ( h*L+A}L. 9*2 &= Y% o%H &h)_ @W K* (Lh*S K* )Lh*P K* ;-Lh*`8????ХL'??B}L+͒???L++,L+ee8?傅?僅8傍?働? $8??????`C} @LO, @ O,L4) @ {, @` @ @ {,L'?m @?m @ͅ?hhL,m @m @8?倅?偅D} M$?m @??m @?`?It?`= Y% 8)})Y`,-Э`2 & > Y% ,L & % %LJ&^懥͒?E}LC)L4)Ƌ^Ƌ̓?L)8ee8内包LM-L'@ԩ-0F}1-XYȑȑ`ppp-.A-Hs) ԍЍ)Х  h@ЭG} 9* &> Y%I $I2 o%)_ @W . )L.S . )L.P . -L. 'L &??`8??H}?? *?? $L5.'U?? T8~ T8? o%?,C09 .n/CL.ɛE~L.~ T8L.) }̓?𻥌)I}Ю ? T8CL.?`2 &Ϡ= Y% ,L &D D D D Lto/j0CL|/C??L/CJ}8?勪,C0ɛ^L/ .&L/^L/ 2` &9> Y% [00@ w/p?D?E8??H??I B V0 oK}/ ';0 LX1H o/h!H} T8Q> Y%h v8 P0 -?` &Y> Y%L70C BLVpCCH@k0f1 .h? &hhL- P0CL}D?E?HICJBLV8??ą &s> Y% [0L0 % 0L0LX1CDE8?冝HM}?凝IB V`CHm??Im???e??e? /??` P0L0} T8ig1b2> Y%L70@ԭs)N})`????8* &?.??.??.??.? ??L1? ?8??????L1?`8????O}?? ? &> Y%?`m?m?8?倅?偅eͅ? &> Y%?` M$?m???c2^3m??P}?? $L'ȱȊ`)?! ;I@Ln(H)h)` @@L2i `Э& &? Y% .@L &?@̔?Q}L &@@S@ .&ъ 拥͒?6@ei?Ō?卐8@@@ '` _3Z4& ? Y%R}?` &8???? v8?`KE:P@HH8@@@@1pHI B@ V( 0LJ&hh@`S} &נ>LY%L5ЭL= &> Y% o1 [0L5 o1 3?? @ @C3? @@3t@??[4V5@T}@?@L5^)@@@?挐?@?ȱ?8ei@ 5@ 58.@??䅎@ 7 5@U}? 258??<:? ?? 25?E T8> Y% o% '; -} T8 &LJ&LX48?@0 5??兎B W5V}R65 7 5 5 5@@?8@@@@ &> Y% o% 3??䅎A 5 7?@0 5` ?@ 3`?m@W}@ 5` 3C 3` @) 25656 @L.7ʊ @6HHG6HF6H`8@eiLX4^@`wlrtbsnhf%p?xmqi6666X}66S6N766766x6n6e6'7P7ȩ@L*6 1@L*6 1@?@L*6 1@?@L*6 1?L*6?L*6 1?L*6 1?L*6 1?LY}*6 1?L*6 1?L*6@ȘH 25h@` 7?A?L*6ȱ^` 7?B?L*6 7L*6ȱ @Ls4 1H @)Z}hd@ *6LO7-86^ 2???`CC 0L3 % 0L3hhpCLN4̏?0 2 3 @  3_ 3L[}7`@) @ 2c8@?J8? 3@L7e8??8? L7u @I @#@@@ q8@L7 @d@ 3L7.8)9 B V\}nD8EHIBLV䌡8HI B V䬡8`E:Lx8Dԅ ؠH),D0 T8L8 3h0``]}D 8D)?<D)@`I@`D9,P a{)ɀ`H2ҢҠh`lj;k+*opui-=vc*99bx^}z436521, .nm/reytwq907~8<>fhdgsaLJ:K\^OPUI_|VCBXZ$#&%"![ ]NM?REYTWQ()'@}FHDGSA {  _} ` }9: 2@ : 2@ &: $L9L &Э# &? Y% .:@?<@̔?`}L &8@@e@@ee8?傅?僅 $8?@???:@) @ @ {,<@ .&:@m:@ia}L':; ';pD>EHIJB V0\DDdDeDDD L;0?+K T8 L;03D L;0) T8DD. T8L: b} L;ƌL:p B VpC`H T8h T8 L;0 T8LA;pHIBLV o1 .8 o1R} T8 : =DDDΘDΘD = o%c};a;<)_ݼ;L<ʊ ;H;H`+*-=RLUF12345678 ;<<0<<<<<=========G=%= =DL< =DDd} DDDL; =D8L< =Di͘DުL<>C) 2 C C.ʎDC`pBDHIDe}CELV CL^;pCJ C< w<0% % 00} T8 - &LJ&T T8LT8@ '; Y=Q> Y%@ v8 T8g}> Y% o% =L< I==` Y=? Y%>LT8=>`124 chr=1 sector.PAGE 6 WRITERExit to DOSBuffer FullDelete (S,W,P):h} Are You Sure? (Y/N)ERASE ALL TEXTErase (S,W,P): to exitSave (Device:Filename)>Error #BREAK Key AbortNo ErrorsLi}oad (Device:Filename)> Press D1:*.*Memory Ful>?lNo text in bufferPrint (Device:Filename)>Printing...Insert nexj}t sheet, press Find:Not FoundChange To: -Exit ̭oad ̭elete ormat nlock ock ename Drive #k}Rename to:Format Diskrive #w8<<  B JKIHiDiELV`L8 8 BLV`Lxm}8t8l Lu8hihiHHȱȱL8c !#3`Lu8JJJJ`H 8h`Hn}ȩh Q8L8 Z8L8 8L8 8L8 8L8S:@9E:E9H '9 H9I9 8 '9h)0ICo}9D9L8 L :::: :Lr:::IEL[::i:iIIL[:`:i::iq}::L:`L{:w:w: C`L:L: D8:MEM.SAV: 8| 9 '9`L:L: D:DUP.SYS:̩ 8r} x:ɀL: '9`88 |9Y:X: '9L); D8:DUP.SYS; 8::88 9 '98? :`;WL`; 9s}Ln; ` :Y;Y;L;L;)} Setting Up ATARI 130XE Ram Disk; 9L; ; -9  t} L;D8:; :9 :Y;L 4D 77 SQR11 17 CLOSE 1F 31 >= } 4E 78 SGN12 18 CLR 2O 32 < 4F 79 ABS13 19 DEG 21 33 > } 5O 8O INT14 2O DIM 22 34 = 51 81 PADDLE15 21 END 23 35 } 52 82 STICK16 22 NEW 24 36 * 53 83 PTRIG17 23 OPEN 25 37 + } 54 84 STRIG18 24 LOAD 26 38 -19 25 SAVE 27 39 /1A 26 STATUS 28 4O NOT1B }27 NOTE 29 41 OR1C 28 POINT 2A 42 AND1D 29 XIO 2B 43 (1E 3O ON 2C 44 )1F 31 POKE }2D 45 = [ARITHM ASSIGN]2O 32 PRINT 2E 46 = [STRING ASSIGN]21 33 RAD 2F 47 <= [STRINGS]22 34 READ 3}O 48 <>23 35 RESTORE 31 49 >=24 36 RETURN 32 5O <25 37 RUN 33 51 >26 38 STOP 34 52 =27 39 }POP 35 53 + [UNARY]28 4O ? 36 54 -29 41 GET 37 55 ( [STRING LEFT PAREN]2A 42 PUT 38 5}6 ( [ARRAY LEFT PAREN]2B 43 GRAPHICS 39 57 ( [DIM ARRAY LEFT PAREN]2C 44 PLOT 3A 58 ( [FUN LEFT PAREN]2D 45 P}OSITION 3B 59 ( [DIM STR LEFT PAREN]2E 46 DOS 3C 6O , [ARRAY COMMA]2F 47 DRAWTO3O 48 SETCOLOR31 49 LOCATE}32 5O SOUNDPAGE 1O-6 ABOVEFT PAREN]2E 46 DOS 3C 6O , [ARRAY COMMA]2F 47 DRAWTO3O 48 SETCOLOR31 49 LOCATE0080COMMANDS OPERATORS FUNCTIONSHEX DEC HEX DEC } HEX DEC-------------------------------------------------------------------------------33 51 LPRINT34 52 CSAVE35 53 C}LOAD36 54 [IMPLIED LET]37 55 ERROR - [SYNTAX]PAGE 1O-7 ABOVE----------------------33 51 LPRINT34 52 CSAVE35 53 CC0080THE TOKEN FILE STRUCTUREThe token file contains two major segments: (1) a group of zero page pointers that point i}nto the token file, and (2) the actual token file itself. The zero page pointers are 2-byte values that point to various sect}ions of the token file. There are Nine 2-byte pointers and they are in locations 8O to 91 hex. Following is a list of the poi}nters and the sections of the token file they reference.Pointer (hex) - Token File Section (Contiguous Blocks)LOMEM 8O,81: } Token output buffer - This is the buffer BASIC uses to tokenize one line of code. It is 256 bytes long. This buffer resid}es at the end of the operating system's allocated RAM.VNTP 82,83: Variable name table - A list of all the variable name}s that have been entered in the program. They are stored as ATASCII characters, each new name stored in the order it was ente}red, Three types of name entries exist:1. Scalar variables - MSB set on the last character in name.2. String variables - la}st character is a "$" with MBS set.3. Array variables - last character is a "(" with the MBS set.VNTD 84,85: Variable }name table dummy end - BASIC uses this pointer to indicate the end of the name table. This normally points to a dummy zero by}te when there are less than 128 variables. When 128 variables are present, this points to the last byte of the variable name}.VVTP 85,87: Variable value table - This table contains current information on each variable. For each variable in the }name table, Eight bytes are reserved in the value table. The information for each variable type is:------------------------}--------------------------------------! Byte Number 1 ! 2 ! 3 4 ! 5 6 ! 7 8 !-----------------------}---------------------------------------! Scalar OO ! Var# ! 6-byte BCD constant !----------------------}----------------------------------------! Array (DIMed) 41 ! Var# ! Offset from ! first ! second !! (unDIMed 4O !} !STARP(8C,8D) ! DIM + 1 ! DIM + 1 !--------------------------------------------------------------! String (DIMed) 81 }! Var# ! Offset from ! Length ! DIM !! (unDIMed) 8O ! !STARP(8C,8D) ! ! !-------------------}-------------------------------------------A scalar variable contains a numeric value. An example is X=1. The scalar is X a}nd its value is 1, stored in 6-byte BCD format. An array is composed of numeric elements stored in the string/array area and }has one entry in the value table. A string, composed of character elements in the string/array area, also has one entry in th}e table.PAGE 1O-8 ABOVE table. A string, composed of character elements in the string/array area, also has one entry in th0080Pointer (hex) - Token File Section (Contiguous Blocks)The first byte of each value entry indicates the type of var }iable: OO for the scalar, 4Ofor an array, and 8O for a string. If the array or string has been dimensioned, then the LSB is s }et on the first byte.The second byte contains the variable number. The first variable entry is number zero, and if 128 varia }bles were present, the last would be 7F.In the case of the scalar variable the third through eighth byte contain the 6-byte }BCD number that has currently been assigned to it.For arrays and strings, the third and fourth bytes contain an offset from }the start of the string/array area (described below) to the beginning of the data.The fifth and sixth bytes of an array cont }ain its first dimension. The quantity is a 16 byte integer and its value is 1 greater than the user entered. The seventh and }eighth bytes are the second dimension, also a value of 1 greater.The fifth and sixth bytes of a string are a bit integer tha }t contains its current length. The seventh and eighth bytes are its dimension (up to32767 bytes size).STMTAB 88,89: State }ment Table - This block of data includes all the lines of code that have been entered by the user and tokenized by BASIC, and } it also includes the immediate mode line. The format of these lines is described in the tokenized line example of the sectio }n on the tokenizing process.STMCUR 8A,8B: Current Satement - This pointer is used by BASIC to reference tokens within a l }ine of the statement table. When BASIC is waiting for input, this pointer is set to the beginning of the immediate mode line. }STARP 8C,8D: String/Array area - This block contains all the string and array data. String characters are stored as one } byte ATASCII entries, so a string of 2O characters will require 2O bytes. Arrays are stored with 6-byte BCD numbers for each } element. A 1O-element array would require 6O bytes.This area is allocated and subsequently enlarged by each dimension state }ment encountered, the amount being equal to the size of the string dimension or six times the size of an array dimemsion.PA }GE 1O-9 ABOVEed, the amount being equal to the size of the string dimension or six times the size of an array dimemsion.PA 0080Pointer (hex) - Token File Section (Contiguous Blocks)RUNSTK 8E,8F: Run time stack - This software stack contai$}ns GOSUB and FOR/NEXT enteries. The GOSUB entry consists of four bytes. The first is a O byte indicating GOSUB, followed by t$}he 2 - byte integer line number on which the call occured. This is followed by the offset into that line so the RETURN can co$}me back and execute the next statement.The FOR/NEXT entry contains 16 bytes. The first is the limit the counter variable can$} reach. The second byte is the step or counter increment. Each of these quantities is in 6 - byte BCD format. The thirteenth $}byte is the counter variable number with the MBS set. The fourteenth and fifteenth bytes are the line number, and the sixteen$}th is the line offset to the FOR statement.MEMTOP 9O,91: Top of application RAM - This is the end of the user program. Pr$}ogram expansion can occur from this point to the end of free RAM, which is defined by the start of the display list. The FRE$} function returns the amount of free RAM by subtrating MEMTOP from HIMEM (2E5,2E6). Note that the BASIC MEMTOP is not the sam$}e as the OS variable called MEMTOP.PAGE 1O-1O ABOVE MEMTOP from HIMEM (2E5,2E6). Note that the BASIC MEMTOP is not the sam$60080THE PROGRAM EXECUTION PROCESSExecutioning a line of code is a process that involves reading the tokens that were c(}reated during the tokenization process. Each token has a particular meaning that causes BASIC to execute a specific series of(} operations. The method of doing this requires that BASIC get one token at a time from the token program and then process it.(} The token is an index into a jump table of routines, so a PRINT token will point indirectly to a PRINT processing routine. W(}hen that processing is complete, BASIC returns to get the next token. The pointer that is used to fetch each token is called (}STMCUR and is at 8A and 8B.The first line of code that is executed in a program is the immediate mode line. This is usually (}a RUN or GOTO. In the case of the RUN, BASIC gets the first line of tokens from the statement table (tokenized program) and p(}rocesses it. If all the code is in-line, then BASIC merely executes consecutive lines.If a GOTO is encountered, then the lin(}e to go to must be found. Thestatement table contains a linked list of tokenized BASIC lines. These lines are stored in ascen(}ding numberical order. To find a line somewhere in the middle of the table, BASIC starts by finding the first line of the pro(}gram.The address of the first line is contained in the STMTAB pointer at 88 and 89. This adress is now stored in a temporary(} pointer. The first 2 bytes of the first line are its line number which is compared against the requested line number. If the(} first number is less, then BASIC gets the next line by adding the third byte of the first line to the temporary pointer. The(} temporary pointer will now be pointing to the second line. Again the first 2 bytes of this new lineare compared to the reque(}st line, and if they are less, the third byte is added to the pointer. If a line munber does match, the contents of the tempo)}rary pointer are moved into STMCUR and BASIC fetches the next token from the new line. Should the request line number not be )}found, an ERROR 12 is generated.The GOSUB involves more processing than the GOTO. The line finding routine is the same, but )}before BASIC goes to that line it sets up an entry in the Run Time Stack. It allocates four bytes at the end of the stack and)} stores a O in the first byte to indicate a GOSUB stack entry. It then stores the line number it was on when the call was mad)}e into the next two bytes of the stack. The final byte contains the offset in bytes from the start line of that line to where)} the GOSUB token was found. BASIC then executes the line it looked up. When the RETURN is found, the entry on the stack is pu)}lled off, and BASIC returns to the callling line.The FOR command causes BASIC to allocate 16 bytes on the Run Time Stack. Th)}e first six bytes are the limit the variable can reach in 6 byte BCD for mat. The second six bytes are the step, in the same )}format. Following these, BASIC stores the variable number (MSB set) of the counting variable. It then stores the present line) } number (two bytes) and the offset into the line. The rest of the line is then executed.PAGE 1O-11 ABOVE the present line(l0080When BASIC finds the NEXT command, it looks at the last entry on the stack. It makes sure the variable referenced b- }y the NEXT is the same as the one on the stack and checks if the counter has reached or exceeded the limit. If not then BASIC- } returns to the line with the FOR statement and continues execution. If the limit was reached, then the FOR entry is pulled o- }ff the stack and execution continues from that point.When an expression is evaluated, the operators are put onto an operator-} stack and are pulled off one at a time and evaluated. The order in which the operators are put onto the stack can either be -}implied, in which case BASIC looks up the operator's precedence from a ROM table, or the order can be explicitly stated by th-}e placement of parentheses.Pressing the BREAK key at any time causes the operating system to set a flag to indicate this occ-}urrence. BASIC checks this flag after each token is processed. If it finds it has been set, it stores the line number at whic-}h this occurred, prints out a "STOPPED AT LINE XXXX" message, clears the BREAK flag and waits for user input. At this point t-}he user could type CONT and program execution would continue at the next line.PAGE 1O-12 ABOVE user input. At this point t,a0080SYSTEM INTERACTIONBASIC communicates with the Operating System primarily through the use of I/O calls to the Centr1}al I/O Utility (CIO). Following is a list of user BASIC calls and the corresponding operating system IOCB (Input/Output Contr1}ol Block) setups. BASIC OSOPEN #1,12,O,"E:" IOCB=1 Command=3 (OPE1}N) Aux1=12 (Input/Output) Aux2=O Buffer Address1}=ADR("E:")GET #1,X IOCB=1 Command=7 (Get Characters) Bu1}fer Length=O Character returned in accumulatorPUT #1,X IOCB=1 1} Command=11 (Put Characters) Buffer Length=OCharacter output through accumulatorINPUT #1,A$1} IOCB=1 Command=5 (Get Record) Buffer Length=Length of A$ (1}not over 12O) Buffer Address=Input Line BufferPRINT #1,AS IOCB=1 1} BASIC uses a special put byte vector in the IOCB to talk directly to the 1} handler.XIO 18,#6,12,O,"S:" IOCB=6 Command=18 (Special - Fill) 1} Aux1=12 Aux2=OSAVE/LOAD: When a BASIC token progeam is saved to a device, two blocks of inform1 }ation are written. The first block consists of seven of the nine zero page pointers that BASIC uses to maintain the token fil1!}e. These are LOMEM (8O,81) through STARP (8C,8D). There is one change made to these pointers when they are written out: The v1"}alue of LOMEM is subtracted from each of the 2-byte pointers, and these new values are written to the device. Thus the first 1#}2-bytes written will be O,O.The second block of information written consists of the following token file section: (1) The va1$}riable name table, (2) the variable value table, (3) the token program, and (4) the immediate mode line.When this program is1%} loaded into memory, BASIC looks at the OS variable MEMLO (2E7,2E8) and adda its value to each of the 2-byte zero page pointe1&}rs as they are read from the device. These pointers are placed back on page zero and then the values of RUNSTK (8E,@F) and ME1'}MTOP (9O,91) are set to the value in STARP.PAGE 1O-13 ABOVE back on page zero and then the values of RUNSTK (8E,@F) and ME0>0080Next, 256 bytes are reserved in memory above the value of MEMLO to allocate space for the token output buffer. Then5)} the token file information, consisting of the variable name table through the immediate mode line, is read in. This data is 5*}placed in memory immediately following the token output buffer. OS BASIC 5+} RAM +----------+ ! ! ! PAGE ! ! SIX !5,} ! !MEMLO 2E7,2E8--->+----------+<--8O,81 LOMEM ! !<--82,83 VNTP 5-} ! !<--84,85 VNTD ! BASIC !<--86,87 VVT ! TOKEN !<--88,89 STMTAB 5.} ! PROGRAM !<--8A,8B STMCUR ! !<--8C,8D STARP ! !<--8E,8F R5/}UNSTK ! !<--9O,91 MEMTOPAPPMHI OE,OF---->+----------+<--OE,OF APHM ! ! 50} ! ! FREE RAM ! ! ! ! FRE (O) ! ! ! 51} ! ! !MEMTOP 2E5,2E6-->+----------++----------+ ! !53} ! SCREEN ! ! RAM ! ! !TXTMSC 294,295-->+----------+ 54} ! ! ! TEXT ! ! WINDOW ! ! !RAMTOP 6A 55} ! ! ------->+----------+RAMSIZ 2E4Figure 7-2 OS and BASIC Pointers (No DOS Present)PAGE 1O-14 A56}BOVE ! ! ------->+----------+RAMSIZ 2E4Figure 7-2 OS and BASIC Pointers (No DOS Present)PAGE 1O-14 A40080IMPROVING PROGRAM PERFORMANCEProgram performance can be improved in two ways. First the execution time can be decr98}eased (it will run faster) and second, the amount of space required can be decreased, allowing it to less RAM. To attain thes99}e two goals, the following lists can be used as guidelines. The methods of improvement in each list are primarily arranged in9:} order of decreasing effectiveness. Therefore the method at the top of a list will have more impact than one on the bottom.S9;}peeding Up a BASIC Program1. Recode - Because BASIC is not a structured language, the code is written in it tends to be inef9<}ficient. After many revisions it becomes even worse. Thus, the time spent to restructure the code is worthwhile.2. Check alg9=}orithm logic - Make sure that the code to execute a process is as efficient as possible.3. Put frequently called subroutines9>} and FOR/NEXT loops at the start of the program - BASIC starts at the beginning of a program to look for a line number, so an9?}y line references near the end will take longer to reach.4. for frequently called operations within a loop use in-line code 9@}rather than subroutines - The program speed can be improved here since BASIC spends time adding and removing entries from the9A} run time stack.5. Make the most frequently changing loop of a nested set the deepest - In this way, the run time stack will9B} be altered the fewest number of times.6. Simplify floating point calculations within the loop - If a result is obtained by 9C}multiplying a constant by a counter, time could be saved by changing the operation to an add of a constant.7. Set up loops a9D}s multiple statements on one line - In this way the BASIC interpreter will not have to get the next line to continue the loop9E}.8. Disable the screen display - If visual information is not important for a period of time, up to a 3O percent time saving9F}s can be made with a POKE 559,O.9. Use a faster graphics mode or a short display list - If a full screen display is not nece9G}ssary then up to 25 percent time savings can be made.1O. Use assembly code - Time savings can be made by encoding loops in a9H}ssembler and using the USR function.PAGE 1O-15 ABOVEO. Use assembly code - Time savings can be made by encoding loops in a870080Saving Space In A BASIC Program1. Recode - As mentioned previously, restructuring the program will make it more ef=J}ficient. It will also save space.2. Remove remarks - Remarks are stored as ATASCII data and merely take up space in the runn=K}ing program.3. Replace a constant used three times or more with a variable - BASIC a allocates seven bytes for a constant bu=L}t only one for a variable reference, so six bytes can be saved each time a constant is replaced with a variable assigned to t=M}hat constant's value.4. Initialize variables with a read statement - A data statement is stored in ATASCII code, one byte pe=N}r character, whereas an assignment statement requires seven bytes for one constant.5. Try to convert numbers used once and t=O}wice to to operations of predefined variables - An example is to define Z1 to equal 1, Z2 to equal 2, and if the number 3 is =P}required, replace it with the expression Z1 + Z2.6. Set frequently used line numbers (in GOSUB and GOTO) to predefined varia=Q}bles - If the line 100 is referenced 50 times, approximately 300 bytes can be saved by equating Z100 to 100 and referencing Z=R}100.7. Keep the number of variables to a minimum - Each new variable entry requires 8 more bytes in the variable value table=S} plus a few bytes for its name.8. Clean up the value and name tables - Variable entries are not deleted from the value and n=T}ame tables even after all references to them are removed from the program. To delete the entries LIST the program to disk or =U}cassette, type new, then ENTER the program.9. Keep variable names as short as possible - Each variable name is stored in the=V} name table as ATASCII information. The shorter the names, the shorter the table.10. Replace text used repeatedly with with =W}strings - On screens with a lot of text, space can be saved by assigning a string to a commonly used set of characters.11. I=X}nitilize strings with assignment statements - An assignment of a string with data in quotes require less space than a READ st=Y}atement and a CHR$ function.12. Concatenate lines into multiple statements - Three bytes can be saved each time two lines ar=Z}e converted into two statements on one line.PAGE 10-16 ABOVEe statements - Three bytes can be saved each time two lines ar<?008013. Replace once used subroutines with in-line code - The GOSUB and RETURN statements waste bytes if only used onceA\}.14. Replace numeric arrays with strings if the data values do not exceed 255 - Numeric array entries require six bytes eachA]}, whereas string elements only need one.15. Replace SETCOLOR statements with POKE commands - This will save 8 bytes.16. useA^} curser control characters rather than POSITION statements - The POSITION statement requires 15 bytes for the X,Y parameters A_}whereas the curser editing characters are one byte each.17. Delete lines of code via program control - See the advanced progA`}ramming techniques section.18. Modify the string/array pointer to load predefined data - By changing the value in STARP, strAa}ing and array information can be saved.19. Small assembly routines can be stored in USR calls - for example X=USR(ADR("hhh*LAb}Vd"),16).20. Chain programs - An example would be an initialization routine that is run first and then loads and executes thAc}e main program.PAGE 10-17 ABOVE example would be an initialization routine that is run first and then loads and executes th@!0080ADVANCED PROGRAMMING TECHNIQUESAn understanding of fundamentals of ATARI BASIC makes it possible to write some intEe}eresting applications. These can be strictly BASIC operations, or they can also involve features of the operating system.ExaEf}mple 1 - String Initialization - This program will set all the first bytes of a string of any length to the same value. BASICEg} copies the first byte of the source string into the first byte of the destination string, then the second, third, and so on.Eq}b%DOS SYSbC)AUTORUN SYSb lRAMDISK COMbuDERE145 bDERE146 bDERE147 bDERE148 bDERE149 bDERE150 b DERE151 bDERE152 b DERE153 bDERE154 b(DERE155 b7DERE156 bIDERE157 b [DERE158 b dDERE159 byDERE160 bDERE161 bDERE162 bDERE163 bDERE164 bDERE165 bDERE166 bDERE167 b,DERE168 bCDERE169 bWDERE170 boDERE171 bDERE172 bDERE173 bDERE174 #DERE175 #DERE176 #DERE177 # DERE178 #DERE179 #+DERE180 #:DERE181 #HDERE182 #VDERE183 #\DERE184 # mDERE185 #xDERE186 #DERE187 # DERE188 #DERE189 # DERE190 #DERE191 #DERE192 #DERE193 #DERE194 By making the destination string the second byte of the source, the same character can be stored throughout the entire strinEr}g.Example 2 - Delete Lines Of Code - By using a feature of the operating system, a program can delete or modify lines of codEs}e within itself. The screen editor can be set to accept data from from the screen without user input. Thus by first setting uEt}p the screen, positioning the curser to the top, and then stopping the program, BASIC will be getting the commands that have Eu}been printed on the screen.Example 3 - Player/Missile (P/M) Graphics With Strings - A fast way to move player/missile graphiEv}cs data is shown in this example. A dimensioned string has its string/array area offset value changed to point to the P/M graEw}phic area. Writing to this string with an assignment statement will now write data into the P/M area at assembly language ratEx}es.PAGE 10-18 ABOVEthis string with an assignment statement will now write data into the P/M area at assembly language ratD008010 REM STRINGS INITIALIZATION20 DIM A$(1000)30 A$(1)="A":A$(1000)="A"40 A$(2)=A$-------------------------------Iz}----10 REM DELETE LINE EXAMPLE20 GRAPHICS 0:POSITION 2,430 ? 70:? 80:? 90:? "CONT"40 POSITION 2.050 POKE 842,13:STOP60 I{}POKE 842,1270 REM THESE LINES80 REM WILL BE90 REM DELETED-----------------------------------100 REM PLAYER/MISSILE EXAMPI|}LE110 DIM A$(152),B$(20)120 X=X+1:READ A:IF A<>-1 THEN B$(X,X)=CHR$(A):GOTO 120130 DATA 0,255,129,129,129,129,129,129,129,I}}129,255,0,-12000 POKE 559,62:POKE 704,882020 I=PEEK(106)-16:POKE 54279,12030 POKE 53277,3:POKE 710,2242040 VTAB=PEEK(134)I~}+PEEK(135)*2562050 ATAB=PEEK(140)+PEEK(141)*2562060 OFFS=1*256+1024-ATAB2070 HI=INT(OFFS/256):LO=OFFS-HI*2562090 POKE VTAI}B+2,LO:POKE VTAB+3,HI3000 Y=60:Z=100:V=1:H=14000 A$(Y,Y+11)=B$:POKE 53248,Z4010 Y=Y+V:Z=Z+H4020 IF Y>213 OR Y<33 THEN V=-I}V4030 IF Z>206 OR Z<49 THEN H=-H4420 GOTO 4000PAGE 10-19 ABOVEKE 53248,Z4010 Y=Y+V:Z=Z+H4020 IF Y>213 OR Y<33 THEN V=-HC0080APPENDIX AMEMORY UTILIZATIONMemory utilization with the Atari Home Computer can be difficult. Much of the memorM}y is commandeered by the operating system, the resident cartridge, or the DOS, leaving very little under the direct control oM}f the programmer. This gives the programmer very little fredom in laying out memory utilization for a program. With proper plM}anning this need not be a serious problem.PAGE ZEROThe most important RAM for any assembly language programmer is page zeroM}. Page zero is absolutely essential for pointers and is very for heavily used variables, because code written for page zero vM}ariables is more compact and runs faster. Hence the assembly language programmer wants to know how many locations on page zerM}o can be stolen for his own use. This appendix will not cover the use of page zero locations as they are defined and used by M}firmware. Instead, it will address only their use when the firmware's function is disabled or ignored.The lower half of pageM} zero (addresses $00-$80) is reserved for use by the operating system. The 128 bytes here are required for the entire array oM}f services that the operating system provides. Most programs will use only a portion of those services. Thus, many locations M}in this region will not be used by the operating system during the programs execution. In particular, the 43 bytes from $50 tM}o $7A are used only by the screen editor and display handler. Many programs will use custom display lists with their own dispM}lay handlers. These 43 bytes would then become available during program execution. Similar reasoning applied to other locatioM}ns dedicated to special functions would free even more space.Unfortunately, there is a major flaw in this reasoning. The sofM}tware department at Atari is constantly evaluating the performance of the operating system and making changes in the code. ThM}ere are now two versions of the operating system---Rev A and Rev B. they are functionally almost identical; software that runM}s under Rev A will almost certainly run under Rev B. More revisions are contemplated and it is higly probable that the underuM}tilization of those 43 bytes will be corrected in future revisions of the operating system. Thus, any software packages that M}steal those 43 bytes, or any other bytes from the lower half of page zero, will probably malfunction if run under a future opM}erating system. therefore, commercially offeres software should not steal any bytes from the lower half of page zero. The prM}ogrammer must look to the upper half of page zero for free bytes. These 128 bytes are reserved for use by the cartridge. If nM}o cartridge is in place, they are free. If a cartridge is in place, some bytes will be reserved for the programmer. The BASICM} cartridge leaves only 7 bytes for the use of the programmer---$CB through $D1. The programmer who must have more page zero bM}ytes has only one option: the bytes used by the floating point package ($D4 to $FF). These 44 bytes may be taken if the floatM}ing point package is not used by the programmer's routines and if those routines do not themselves call the floating point paM}ckage. PAGE A-1 ABOVE used by the programmer's routines and if those routines do not themselves call the floating point paL0080The programmer does not have unlimited use of these bytes; they must not be used by any interrupt routines, as suchQ} routines might strike during a floating point operation called BASIC. There are np other bytes on the upper half of page zerQ}o usable by the programmer. The programmer working in a BASIC environment is seldom interested in the high performance andQ} compactness that page zero offers; after all, if high speed and compactness were primary concerns, the programmer would not Q}have chosen BASIC as a delivery language. The programmer most interested in large amounts of page zero is the assembly languaQ}ge programmer. A pure assembly language program does not need any cartridge installed to run; therefore it should have accessQ} to all 128 bytes of the upper half of page zero. In practice this is not quite so simple, for an assembly language pprogram Q}must be debugged, and the only convenient way to do this at present is with the debugger in the Atari Assembler-Editor cartriQ}dge. Assembly language programmers will note with chagrin that this cartridge only reserves 32 bytes ($BO-$CF) for their own Q}use. While this is entirely adequate for virtually any program it is not enough to satiate the appetite of a high-performanceQ} program. There are 30 more bytes that are not used by the debugger portion of the cartridge. These are: $A4, $A5, $AD, $AE, Q}$DB through $E5, $EA through $F1, $F5, $F6, $F9 through $FB, $FE, and $FF. If these bytes are used the programmer must not reQ}turn to the Editor or the Assembler or bad things may happen. Furthermore, the mini-assembler inside the debugger must not beQ} used. If you use other cartridges or disk-based languages, you are on your own. Many of these systems use even more of paQ}ge zero.ABSOLUTE RAM Another problem the programmer faces is presented by the DOS. It is very desirable to write programQ}s that run on either 16K cassette systems or 48K diskette systems. Unfortunately, such systems have very little free RAM in cQ}ommon, for the DOS and DUP would almost fill the RAM of the 16K system. There are several solutions to this problem. One is tQ}o produce two different versions of the code, a disk version and a cassette version. The two programs would be urged to diffeQ}rent locations. This means that customers who buy the cassette version will not be able to transport it to a diskette if theyQ} upgrade their systems. There is another way. Page six is common free RAM for all systems. Variables and vectors can be plQ}aced on page six and used by cassette-based software or diskette-based software. A directory of routine addresses can be compQ}uted and placed at run-time onto page six. Machine language routines can then jump through the page six directory to the routQ}ines elsewhere in RAM. The technique can be difficult to execute; it is not recommended for large assembly language projects.Q} Its greatest value is with medium-size machine language routines (about 1K-2K) embedded inside BASIC programs.PAGE A-2 ABOQ}VEs greatest value is with medium-size machine language routines (about 1K-2K) embedded inside BASIC programs.PAGE A-2 ABOP0080APPENDIX BHUMAN ENGINEERINGThe atari home computer is first and foremost a consumer computer. The hardware was U}designed to make this computer easy for consumers to use. Many of the hardware features protect the consumer from inadvertentU} errors. Software written for this computer should reflect an equal concern for the consumer. The average consumer is unfamilU}lar with the conventions and traditions of the computer world. Once he understands a program he will use it well most of the U}time. Occasionally he will be careless and make mistakes. It is the programmer's responsibility to try to protect the consumeU}r from his own mistakes.The current state of software human engineering in the personal computer industry is dismal. A greatU} many programs are being sold that contain very poor human engineering. The worst offenders are written by amateur programmerU}s, but even software written at some of the largest firms shows occasional lapses in human engineering.Human engineering is U}an art, not a science. It demands great technical skill but it also requires insight and feel. As such it is a highly subjectU}ive field devoid of absolutes. This appendix is the work of one hand, and so betrays the subjectivities of its author. A propU}er regard for the wide variety of options on the subject would have inflated this appendix beyond all reasonable limits of leU}ngth. Furthermore, a complete presentation of all points of view would only confuse the reader with its many assertions, qualU}ifications, counterpoints, and contradictions. I therefore chose the simpler task of presenting only my own point of view, giU}ving weak lip service to the most serious objections. The result is contradictory enough to satisfy even the most academic ofU} readers.THE COMPUTER AS SENTIENT BEINGAn instructive way of viewing the problem of human engineering is to cast the prograU}mmer as sorcerer, conjuring up an intelligent being, a homunculus, within the innards of the computer. This creature lacks phU}ysical embodiment, but possesses intellectual traits, specifically, the ability to process and organize information. The userU} of the program enters into a relationship with this homunculus. The two sentient beings think differently; the human's thougU}ht patterns are associative, integrated, and diffuse, while the program's thought processes are direct, analytical, and speciU}fic. These differences are complementary and productive because the homunculus can do well what the human cannot. UnfortunateU}ly, these differences also create a communications barrier between the human and the homunculus. They have so much to say to U}each other because they are so different, but because they are different they cannot communicate well. The central problem inU} good programming must therefore be to provide for better communications between the user and the homunculus. Sad to say, manU}y programmers expend the greater part of their efforts of expanding and improving the processing power of their programs. ThiU}s only produces a more intelligent being with no eyes to see and no mouth to speak.PAGE B-1 ABOVEer of their programs. ThiTd0080The current crop of personal computers have attained throughputs which make them capable of sustaining programs intY}elligent enough to meet many of the average consumer's needs. The primary limiting factor is no longer clock speed or residenY}t memory; the primary limiting factor is the thin pipeline connecting our now-intelligent homunculus with his human user. EacY}h can process information rapidly and efficiently; only the narrow pipeline between them slows down the interaction.COMMUNICY}ATION BETWEEN HUMAN AND MACHINEHow can we widen the pipeline between the two thinkers? we must focus on the language with whY}ich they communicate. Like any language, a man-machine language is restricted by the physical means of expression available tY}o the speakers. Because the computer and the human are physically different, their modes of expression are physically differeY}nt. This forces us to create a language which is not bidirectional (as human languages are). Instead, a man-machine language Y}will have two channels, an input channel and an output channel. Just as we study human language by first studying the sounds Y}that the human vocal tract can generate, we begin by examining the physical components of the man-machine interface.OUTPUT (Y}FROM COMPUTER TO HUMAN)There are two primary output channels from the computer to the user. The first is the television screY}en; the second is the television speaker. Fortunately, these are flexible divices which permit a broad range of the computer'Y}s point of view. For the purposes of this appendix, it is more usefull to discuss these divices in terms of the human point oY}f view. Of the two devices (screen and speaker) the display screen is easily the more expressive and powerful device. The humY}an eye is a more finely developed information gathering device than the human ear. In electrical engineering terms, it has moY}re bandwidth than the ear. The eye can process three major forms of visual information: shapes, color, and animation.SHAPESY}Shapes are an ideal means for presenting information to the human. The human retina is especially adept at recognizing shapesY}. The most direct use of shapes is for direct depiction of objects. If you want the program to tell the user about something,Y} draw a picture of it. A picture is direct, obvious, and immediate.The second use of shapes is for symbols. Some concepts inY} the human lexicon defy direct depiction. Concepts like love, infinity, and direction cannot be shown with pictures. They musY}t instead be conveyed with symbols, such as a heart, a horizontal figure 8, or an arrow. These are a few of the many symbols Y}that we all recognize and use. Sometimes you can create an ad hoc symbol for limited use in your programs. Most people can piY}ck up such an ad hoc symbol quite readily.PAGE B-2 ABOVE ad hoc symbol for limited use in your programs. Most people can piX:0080Symbols are a compact way to express an idea but they should not be used in place of pictures unless compactness is]} essential. A symbol is an indirect expression; a picture is a direct expression. The picture conveys the idea more forcefull]}y.The third and most common use of shapes is for text. A letter is a symbol; we put together to form words. The language we ]}thereby produce is extremely rich in its expressive power. Truly is it said, "if you can't say it, you don't know it." this e]}xpressive power is gained at a price: extreme indirection. The word that expresses an idea has no sensory or emotional connec]}tion with the idea. The human is forced to carry out extensive mental gymnastics to decipher the word. Of course, we do not n]}otice the effort. The important point is that the indirection detracts from the immediacy and forcefulness of the communicati]}on.There is a school of thought that maintains that text is superior to graphics for communications purposes. The gist of th]}e arguement is that text encourages freer use of the reader's rich inagination. The arguement does not satisfy me, for if the]} reader must use his imagination, he is supplying information that is not inherent in the communication itself. An equal exer]}cise of imagination with graphics would provide even greater results. A more compelling arguement for text is that its indire]}ction allows it to pack a considerable amount of information into a small space. The space constraints on any real communicat]}ion make text's greater compactness valuable. Nevertheless, this does not make text superior to graphics; it make text more e]}conomical. Graphics requires more space, time, memory, or money, but it also communicates better than text. To some extent, t]}he choice between graphics and text is a matter of taste, and the taste of the buying public is beyond question. Compare the ]}popularity of television with that of radio, or movies with books. Graphics beats text easily.COLORColor is another vehicle]} for conveying information. It is less powerful than shape, and so normally plays a secondary role to shape invisual presenta]}tion. Its most frequent use is to differentiate between otherwise indistinguishable shapes. It also plays an important role i]}n providing cues to the user. Good color can salvage an otherwise ambiguous shape. For example, a tree represented as a chara]}cter must fit inside an 8*8 pixel grid. The grid is too small to draw a recognizable tree; however, by coloring the tree gree]}n, the image becomes much easier to recognize. Color is also useful for attracting attention or signalling important material]}. Hot colors attract attention. Color also provides the aesthetic enhancement. Colored images are more pleasing to look at th]}an black and white images.ANIMATIONI use the term "animation" here to designate any visual change. Animation includes chang]}ing colors, changing shapes, moving foreground objects, or moving the background. Animation's primary value is for showing dy]}namic processes. Indeed, graphic animation is the only way to successfully present highly active events. PAGE B-3 ABOVEdy\{0080The value of animation is most forcefully demonstrated by a game like star raiders. Can you imagine what the game wa}ould be like without animation? For that matter, can you imagine what it would be like in pure text? The value of animation ea}xtends far byond games. Animation allows the designer to clearly show dynamic, changing events. Animation is one of the majorb} advantages that computers have over paper as an information technology. Finally, animation is very powerful in sensory termsb}. The human eye is organized to respond strongly to changes in the visual field. Animation can attract the eye's attention anb}d increase the user's involvement in the program.SOUNDGraphics images must be looked at to have effect. Sound can reach theb} user even when the user is not paying direct attention to the sound. Sound therefore has great value as an annunciator or wab}rning cue. A wide variety of beeps, tones, and grunts can be used to signal feedback to the user. Correct actions can be answb}ered with a pleasant bell tone. Incorrect actions can be answered with a raspberry. Warning conditions can be noted with a hob}nk.Sound has a second use: providing realistic sound effects. Quality sound effects can greatly add to the impact of a progrb}am because the sound provides a second channel of information flow that is effective even when the user is visually occupied.b}Sound is ill-suited for conveying straight factual information; most people do not have the aural acuity to distinguish fineb } tone differences. Sound is much more effective for conveying emotional states or responses. Most people have a large array ob }f associations of sounds with emotional states. A descending sequence of notes implies deteriorating circumstances. An explosb }ion sound denotes destruction. A fanfare announces an important arrival. Certain note sequences from widely recognized populab }r songs are immediately associated with particular feelings. For example, in energy czar, a funeral dirge tells the user thatb } his energy mismanagement had ruined America's energy situation, and a fragment of "happy days are here again" indicates sucb}cess.Input devices (from human to computer)There are three input devices most commonly used with the atari home computer. Tb}hese are the keyboard, joystick, and paddles.KeyboardThe keyboard is easily the most powerful input device available to theb} designer. It has over 5 direct keystrokes immediately available. Use of the control and shift keys more than doubles the numb}ber of distinguishable entries the user can make. The CAPS/LOWR and the atari keys extend the expressive range of the keyboarb}d even further. Thus, with a single keystroke the user can designate one of 125 commands. PAGE B-4 ABOVEnge of the keyboar`k0080A pair of keystrokes can address more than 15,000 selections. Obviously, this device is very expressive; it can easf}ily handle the communications needs of any program. For this reason the keyboard is the input device of choice among programmf}ers.While the strengths of the keyboard are undeniable, its weaknesses are seldon recognized. Its first weakness is that notf} many people know how to use it well. Programmers use keyboards heavily in their daily work; consequently, they are fast typif}sts. The average consumer is not so comfortable with a keyboard. He can easily press the wrong key. The very existence of allf} those keys and the knowledge that one must press the correct key is itself intimidating to most people.A second weakness off} the keyboard is its indirection. It is very hard to attach direct meaning to a keyboard. A keyboard has no obvious emotionalf} or sensory significance. The new user has great difficulty linking to it. All work with the keyboard is symbolic, using buttf}ons which are marked with symbols which are assigned meaning by the circumstances. The indirection of it all can be most conff}using to the beginner. Keyboards also suffer from their natural association with text displays; I have already discussed the f}weaknesses of text as a medium for information transfer.Another property of the keyboard that the designer must keep in mindf} is its digital nature. The keyboard is digital both in selection and in time. This provides some protection against errors. f}Because keystroke reading over time is not continous but digital, the keyboard is not well-suited to real-time applications. f }Since humans are real-time creatures, this is a weakness. The designer must realize that use of the keyboard will nudge him af!}way from real-time interaction with his target user.PaddlesPaddles are the only truly analog input devices readily availablf"}e for the system. As such they suffer from the standard problem all analog input devices share: the requirement that the userf#} make precise settings to get a result. Their angular resolution is poor, and thermal effects produce some jitter in even an f$}untouched paddle's output.Their primary value is twofold. First, they are well-suited for choosing values of a one-dimensionf%}al variable. People can immediately pick up the idea that the paddle sweeps through all values, and pressing the trigger makef&}s the selection known. Second, the user can sweep from one end of the spectrum to the other with a twist of the dial. This maf'}kes the entire spectrum of values immediately accessible to the user.An important factor in the use of paddles is the creatif(}on of a closed input/output loop. In most input processes, it is desirable to echo inputs to the screen so that the user can f)}verify the input he has entered. This echoing process creates a closed input/output loop. Information travels from the user tf*}o the input device to the computer to the screen to the user. Because the paddle has no absolute positions, echoing is essentf+}ial.Any set of inputs that can be meaningfully placed along a linear sequence can be addressed with a paddle. B-5s essentdu0080For example, menus can be addressed with a paddle. The sequence is from the top of the menu to the bottom. It is quj-}ite possible (but unreasonable) to substitute a paddle for a keyboard. The paddle sweeps through the letters of the alphabet,j.} with the current letters being addressed shown on the screen. Pressing the paddle trigger selects the letter. While the schej/}me would not produce any typing speed records, it is useful for children and the idea could be applied to other problems.Joyj0}sticksJoysticks are the most simplest input devices available for the computer. They are very sturdy and so can be used in hj1}arsh environments. They contain only five switches. For this reason their expressive power is frequently underestimated. Howej2}ver, joysticks are surprisingly useful input devices. When used with a curser, a joystick can address any point on the screenj3}, making a selection with the red button. With proper screen layout, the joystick can thus provide a wide variety of control j4}functions. I have used a joystick to control a nuclear reactor (scram) and run a wargame (eastern front 1941).The key to thej5} proper use of the joystick is the realization that the critical variable is not the selection of a switch, but the duration j6}of time for which the switch is pressed. By controlling how long the switch is pressed, the user determines how far the cursej7}r moves. This normally requires a constant velocity curser. A constant velocity curser introduces a difficult trade-off. If tj8}he curser moves too fast, the user will have difficulty positioning it on the item of choice. If the curser moves too slowly,j9} the user will become impatient waiting for it to traverse long screen distances. One solution to this problem is the accelerj:}ating curser. If the curser starts moving slowly and accelerates, the user can have both fine positioning and high speed.Thej;} real value of the joystick is its high tactility. The joystick involves the user in his inputs in a direct and sensory way. j<}The tactility of the keyboard is not emotionally significant. A joystick makes sense---push up to go up, down to go down. If j=}the curser reflects this on the screen, the entire input process makes much more sense to the user.Joysticks have their limij>}tations. Although it is possible to press the joystick in a diagonal direction and get a correct reading of the direction, thj?}e directions are not distinct enough to allow diagonal entries as a separate commands. Just as some words (e.g., "library, "Fj@}ebruary") are hard to enunciate clearly, so too are diagonal orders hard to enter distinctly. Thus, diagonal values should bejA} avoided unless they are user in the pure geometrical sense: up on the joystick means up, right means right, and diagonally mjB}eans diagonally.PAGE B-6 ABOVEthe pure geometrical sense: up on the joystick means up, right means right, and diagonally mh!0080SUMMARY OF COMMUNICATIONS ELEMENTSWe have discussed a number of features and devices which, taken together, constinD}tute the elements of a language for interaction between the computer and the user. They are: Shapes color animation sonE}und========== ======= =-------------------->= ==computer= =user== nF} =<--------------------= =========== ====== keyboard paddles joystickConstructing a languanG}geHow do we assemble all of these elements into an effective language? To do so, we must first determine the major traits wenH} expect of a good language:- completeness- directness- closureCompletenessThe language must completely express all of thnI}e ideas that need to be communicated between the computer and the user. It need not express ideas internal to either thinker'nJ}s thought processes. For example, the language used in star raiders must express all concepts related to the control of the vnK}essel and the combat situation. It need not express the player's anxiety or the flight path intentions of the Zylons. These cnL}oncepts, while very germane to the entire game function, need not be communicated between user and computer.Completeness is nM}an obvious function of any language, one that all programmers reconize intuitively. Problems with completeness most often arnN}ise when the programmer must add functions to the program, functions which cannot be supported by the language the programmernO} has created. This can be quite exasperating, for in many cases the additional functions are easily implemented in the progranP}m itself. The limiting factor is always the difficulty of adding new expressions to the I/O language.DirectnessAny new langnQ}uage is hard to learn. No user has time to waste in learning an unnecessarily florid language. The language a programmer creanR}tes for a program must be direct and tp the point. It must rely as much as possible on communications conventions that the usnS}er already knows. It must be emotionally direct and obvious. For example, a conrol x keystroke is obscure. What does it mean?nT} Perhaps it means something should be destoryed; x implies elimination or negation. Perhaps it implies that something should nU}be examined, expunged, exhumed, or something similar. If none of these possibilities are indeed the case, then the command isnV} unacceptably indirect. Keyboards are notorious for creating this kind of problem.PAGE B-7 ABOVEcase, then the command isld0080ClosureClosure is the aspect of communications design that causes the greatest problems. The concept is best explarX}ined with an analogy. The user is at point a and wishes tp use the program to get to point b. A poorly human-engineered progrrY}am is like a tightrope stretched between points a and b. The user who knows exactly what to do and performs perfectly will surZ}cceed. More likely, he or she will slip and fall. Some programs try to help by providing a manual or internal warnings that tr[}ell the user what to do and what not to do. These are analogous to signs along the tightrope advising "be careful" and "don'tr\} fall." I have seen several programs that place signs underneath the tightrope, so that the user can at least see why he fair]}led as he plummets. A somewhat better class of programs provide masks against illegal entries. These are equivalent to guardrr^}ails alongside the tightrope. These are much nicer, but they must be very well constructed to ensure that the user does not tr_}hwart them. Some programs have nasty messages that bark at the errant user, warning against making certain entries. These arer`} analogous to scowling monitors in the school halls, and are useful only for making an adult feel like a child. The ideal prora}gram is like a tunnel bored through solid rock. There is but one path, leading to success. The user has no options but to sucrb}ceed.The essence of closure is the narrowing of options, the elimination of possibilities, the placement of rock solid wallsrc} around the user. Good design is not an accumulative process of piling lots of features onto a basic architecture; good desigrd}n requires the programmer to strip away minor features, petty options, and general trivia.This thesis clashes with the valuere}s of many programmers. Programmers crave complete freedom to exercise power over the computer. Their most common complaint agrf}ainst a program is that it somehow restricts their options. Thus, deliberate advocacy of closure is met with shocked incredulrg}ity. Why would anyone be so foolish as to restrict the power of this wonderful tool?The answer lies in the difference betweerh}n the consumer and the programmer. The programmer devotes his life to the computer; the consumer is a casual aquaintance at bri}est. The programmer uses the computer so heavily that it is cost-effective to take the time to learn to use a more powerful trj}ool. The consumer does not have the time to lavish on the machine. He wants to get to point b as quickly as posible. He does rk}not care for the fine points that occupy a programmer's life. Bells and whistles cherished by programmers are only trivia to rl}him. You as a programmer may not share the consumer's values, but if you want to maintain your livelihood you had better caterm}r to them.Closure is obtained by creating inputs and outputs that do not admit illegal values. This is extremely difficult trn}o do with a keyboard, for a keyboard always allows more entries than any real program would need.PAGE B-8 ABOVEdifficult tpr0080This is an excellent argument against the use of the keyboard. A joystick is much better, because you can do so litvp}tle with it. Because it can do so little, it is easier to conceptually exclude bad inputs. The ideal is achieved when all necvq}essary options are expressible with the joystick, and no further options will fit. In this case the user cannot make a bad envr}try because it doesn't exsist. More important, like newspeak in Orwell's "1984", the user cannot even conceive bad thoughts bvs}ecause no words (inputs) for them even exist.Closure is much more than masking out bad inputs. Masking makes bad inputs concvt}eivable and expressible, but not functional. For example, a keyboard might be used with the "M" key disabled because it is mevu}aningless. The user can still see the key, he can imagine pressing it. And he can wonder what would happen if he did press itvv}---all wasted effort. The user can waste even more time by pressing it and wondering why nothing happened. The waste is compovw}unded by the programmer imagining the user doing all these wasteful things and putting in code to stop the symptoms without evx}liminating the disease. By contrast, a properly closed input structure uses an input device which can express only the entrievy}s necessary to run the program, and nothing more. The user can't waste time messing with something that isn't there.The advavz}ntages that accrue when closure is properly applied are manifold. Code is tighter and runs faster because there need be no inv{}put error checking; such errors are obsolete in the new program. The user requires less time to learn the program and has fewv|}er problems with it.The primary problem with closure is the design effort that must be expended to achieve good closure. thev}} entire relationship between the user and the program must be carefully analyzed to determine the minimum vocabulary necessarv~}y for the two to communicate. Numerous schemes of communication must be examined and discarded before the true minimum schemev} is found. In the process, many bells and whistles that the programmer wanted to add will have to be eliminated. If the progrv}ammer objectively looks beyond his own values, he will often conclude that the bells and whistles are more clutter than chromv}e.ConclusionsThe design of the language of communication between the user and the program will be the most difficult part ov}f the design process in consumer software. The designer must carefully weigh the capabilities of the machine and the needs ofv} the user. He must precisely define the information that must flow between the two sentient beings. He must then design his lv}anguage to maximize the clarity (not the quantity) of information flowing to the user while minimizing the effort the user muv}st expend to communicate with the computer. His language must utilize the machine's features and devices effectively while mav}intaining its own completeness, directness, and closure. PAGE B-9 ABOVEmachine's features and devices effectively while matJ0080SOME COMMON PROBLEMS IN HUMAN ENGINEERINGHaving discussed the problems of human engineering in theoretical terms, z}we now turn to discuss specific application problems in human engineering. The list of problems is not exhaustive; it merely z}covers some of the problems common to almost all programs.Delay timesMany programs require extensive computations. Indeed, z}almost all programs execute at some time computations that take more than a few seconds to perform. What does the user experiz}ence while these computations are executed? Too many programs simply stop the dialogue with the user for the duration of the z}computation. The user is left with an inactive screen and no sign of life from the computer. The computer does not respond toz} the user's inputs. If human engineering is created by the language of communication between the computer and the user, then z}this complete absence of communication can only be regarded as a total lack of human engineering. Leaving the user in the lurz}ch like this is absolutely unforgiveable.Separate processesThe best way to deal with the problem of reconciling computationz}s with attentiveness is to separate the input process from the computational process. The user should be able to make inputs z}while the computations are proceeding. This is technically achievable; by using vertical blank interrupts the programmer can z}multitask input processing with mainline processing. The technique is used in eastern front 1941. The real problem with this z}technique is that many problems are intrinsically sequential in nature. It is essential that the user input a value or choicez} before the computation can proceed to the next step. This makes it difficult to separate input processing from the mainline z}processing. However, it is possible with clever design to perform anticipatory calculations that will determine intermediate z}values so that as soon as the critical data is entered, the result might be more quickly obtained. Application of such techniz}ques can surely reduce the delay times that the user experiences.Speed up the programAnother means of dealing with this proz}blem is to speed up the program itself. Critical code of loops (the loop with more iterations should be inside the loop with z}fewer iterations) can reduce execution time. Careful attention to the details of execution can yield further time reductions.z} Major gains can be made by converting basic to assembly language. Assembly is from 1 to 1O times faster than basic. Assemblyz}'s advantage is greatest for memory move routines and graphics and least for floating point calculations. By masking out vertz}ical blank interrupts, more 6502 execution time can be freed for mainline processing. Other gains can be accomplished by reduz}cing the DMA overhead antic imposes. This can be done by going to a simple graphics mode (basic mode 3 is best). Shortening tz}he display list is another way to reduce DMA costs.PAGE B-10 ABOVEimple graphics mode (basic mode 3 is best). Shortening txE0080Turning off antic altogether is a drastic route which only creates the additional problem of presenting the user wi~}th a blank screen.Entertain the userThe third way to deal with delay times is to occupy the user during the computation. A ~}countdown is one such method. The user sees a countdown on the screen. When the countdown reaches zero, the program is back i~}n business. Another way is to draw random graphics on the screen. The delay period should always start with a courteous messa~}ge advising the user of the delay. It should also be terminated with a bell or other annunciator. You should not expect the u~}ser to keep his eyes on the screen for an arbitrary period of time. Entertaining the user during delays is a poor way to deal~} with delays that shouldn't have been there in the first place, but it's better than abandoning the user.Dealing with bad us~}er inputsThe most serious problem with present consumer software is the inadequate way that bad user inputs are handled. Goo~}d designs preclude this problem by providing input languages that do not make any bad entries available. As I pointed out ear~}lier, this is most easily accomplished with a joystick. However, there are applications (primarily text-intensive ones) that ~}require a keyboard. Furthermore, even joysticks occasionally introduce problems with user input. How are such bad inputs to b~}e dealt with when they cannot be expunged? Several suggestions follow. It is imperative that any protection system be applied~} uniformly throughout the entire program. Once the user encounters protection, he will expect it in all cases. The lack of su~}ch protection creates a gap through which the user, thinking himself secure, will surely plunge.Flag the Error and Suggest S~}olutionThe most desirable approach in this unpleasant situation is to flag the user's error on the screen in plain language ~}and suggest a correct entry. Three things must be included in the computer's response. First, the user's entry must be echoed~} back so he knows what he did that caused the problem. Second, the offending component of the entry must be clearly marked an~}d explained so that the user knows why it is wrong. Third, an alternate legal entry must be suggested so that the user does n~}ot become frustrated by the feeling that he has encountered a brick wall. For example, an appropriate response to a bad keyst~}roke entry might read thusly: "you pressed control-a, which is an autopsy request. I cannot perform autopsies on living peopl~}e. I suggest you kill the subject first."This method is obviously very expensive in terms of program size and programming ti~}me. That is the price one pays for bad design. There are less expensive and less effective methods.PAGE B-11 ABOVEmming ti|u0080Masking out bad keysOne common solution to keyboard input problems is to mask out all bad entries. If the user pre}sses a bad key, nothing happens. No keyboard click is generated and no character appears on the screen. The program only hear}s what it wants to hear. This solution is secure in that it prevents program crashes, but it does not protect the user from c}onfusion. The user would only press a key if he felt that it would do something for him. Masking out the key cannot correct t}he user's mistaken impression. It can only lead him to the conclusion that something is seriously wrong with his computer. We} don't want to do this to our users.A variant on this scheme is to add a nasty buzzer or raspberry to chastise the user for }his foolishness. Indeed, some amateurish programs go so far as to heap textual abuse on the user. Such techniques are highly }questionable. There may indeed be cases requiring dangerous keystroke entries which are guarded by fierce and nasty messages;} such cases are quite rare.Corrective messages should always conform to high standards of civility.Error messagesAn even ch}eaper solution is to simply post an error message on the screen. The user is told only that he did something wrong. In many c}ases, the error message is cryptic and does not help the user in the least. Atari basic is an extreme example of this. Error }messages are provided by number only. This can be justified only when the program must operate under very tight memory constr}aints.In most cases, the designer chooses to sacrifice human engineering features such as meaningful error messages for some} additional technical power. As pointed out in the beginning of this appendix, we are reaching the stage in which additional }technical power is no longer a limiting factor to consumers, but human engineering is a limiting factor. Thus, the trade-off }is less justifiable.Protection/power trade-offsOne objection to many human engineering features is that they slow down the }user's interaction with the computer. Programmers tire of incessant "are you sure?" requests and similar restrictions. One so}lution to this problem is to provide variable protection/power ratios. For example, a program can default to a highly protect}ed state on initialization. All entries are carefully checked and echoed to the user for confirmation. The user has an option} to shed protection and work in high-speed mode. This option is not obvious from the screen---it is only described in the doc}umentation. Thus, the intensive user can work at a fast pace and the casual user can have adequate protection.PAGE B-12 ABO}VEntation. Thus, the intensive user can work at a fast pace and the casual user can have adequate protection.PAGE B-12 ABO0080MENUS AND SELECTION TECHNIQUESMenus are standard devices for making the user aware of the options available. They }are especially useful for beginning users. Command-oriented schemes preferred by programmers confuse beginners who cannot aff}ord the time investment to learn the lexicon of commands used by a command-oriented program. We will discuss several common p}roblems associated with the use of menus.Menu sizeHow many entries should be on a menu? The obvious upper limit is dictated} by the size of the screen, but this limit is too large, for a basic mode O screen could hold up to 48 entries (24 lines with} two choices per line). My guess is that seven entries is the desired upper limit on menu size. This allows plenty of screen }space to seperate the entries, provide a menu title, and some sort of prompt.Multiple menusFrequently a program will requir}e several menus to fully cover all of the options it offers. It is very important that multiple menus be organized in a clear} manner. The user can easily get lost wondering around through such menu mazes. One way is to have a main menu that is promin}ently marked as such, and provide each secondary menu with an option to return to the main menu. Another way is to nest menus} in a hierarchical structure. When using such methods, the programmer must provide color and sound cues to help the user asce}rtain his position in the menu structure. Each menu or menu level should have a distinctive note or color assigned to it. The} note frequency should be associated with the position in the hierarchy.Selection methodsOnce the user has seen his options}, how does he make his choice known to the computer? The most common way is to label each entry on the menu with a letter or }number; the user makes his selection by pressing the corresponding key on the keyboard. This is a clumsy solution involving u}nnecessary indirection. There are a number of better methods. Most of them use the same basic scheme: a moveable pointer addr}esses an option, and a trigger selects it. One scheme highlights the option being addressed in inverse video. The select butt}on changes the pointer to address the next menu selection, with full wraparound from the end of the menu to the beginning. Th}e start button engages a menu option. Another program automatically rotated the pointer through the menu options; the user ne}ed only push a button at the correct moment when his desired option was being addressed (not an impressive method). Paddles a}nd joysticks are very well suited for menu selection. Either one can be used to sweep the pointer through the menu selections}, with the red trigger button making the selection. My pet scheme for menu selection uses a curser on a large scrolling menu.} The user moves the curser with a joystick. Signposts can direct here to different regions of the menu. The user makes a sele}ction by placing the curser directly on top of an option and pressing the trigger button.PAGE B-13 ABOVE user makes a selek0080MANUALS VERSUS ON-BOARD TEXTA common problem with menus, error messages, prompts, and other messages is that such }material can easily consume a large amount of memory---memory that could well be used for other features. Such material could} be placed in a reference document, but doing so would detract from the quality of the program's human engineering. The desig}ner must decide how much material should go into the program and how much should be relegated to the manual. With disk-based }programs it is possible to store some of the material on the diskette; this lessens the harshness of the trade-off. When the }problem is approached only from the human engineering point of view, it is easily answered: all material should be included i}n the program, or at least on a diskette. Economic and technical considerations argue against this. It is my personal view th}at each technology should be used for the things it does best. While the computer can handle static text, its forte is dynami}c information processing. Paper and ink handle static information more cheaply and often more clearly than a computer. I ther}efore prefer to put static information into a manual and let the program refer the user to the manual. I still include critic}al information within the program; my dividing line bends with local needs.Measures of successHow can a designer determine }the success of his human engineering? There are several indicators that provide valuable feedback. The first is the minimum l}ength if the manual. If you exclude background material and isolate only the material in the manual that is absolutely necess}ary to describe how to use the program, then the length of this material is a good measure of your human engineering. The mor}e material, the worse you've done. A well designed program should require very little explanation. This should not be constru}ed as an arguement against proper documentation. Documentation should always describe the program in more detail than is abso}lutely necessary. A long lavish manual is good; a program that demands such a manual is not.Another measure is the amount of} time that a first-time user expends to learn to use the program satisfactorily. Good programs can be used in a matter of min}utes.A third measure is the amount of thinking a user must do to use the program. A well-designed program should require no }cognitive effort to use. This does not mean that the user does not think at all while using such a program. Rather, he thinks} about the content of the program rather than the mechanics of the program. He should concentrate on what he is doing, not ho}w he does it.The well-engineered program eliminates mental distance between the user and the computer. The two thinking bein}gs achieve a mental syntony, an intellectual communion.PAGE B-14 ABOVEeen the user and the computer. The two thinking beinI0080APPENDIX CTHE ATARI CASSETTEThis discussion of the ATARI 41O PROGRAM RECORDER includes the following topics:HO}W THE CASSETTE WORKS. Information on the hardware and software used to operate the cassette.CASSETTE APPLICATIONS. How to mi}x audio and digital information to produce a user-oriented program.PAGE C-1 ABOVEHOW THE CASSETTE WORKSRECORD STRUCTUREB}yte DefinitionThe OS writes files in fixed-length blocks at 6OO baud (physical bits/second). Asynchronous serial transmissio}n is used to read and write data between the atari 4OO/8OO computers and the atari program recorder. Pokey recognizes each da}ta byte in this order: 1 start bit (space), 8 data bits (O=space, 1=mark), then one stop bit (mark). A byte is sent/recieved }least significant bit first.The frequency used to represent a mark is 5327 hz. For a space, the frequency is 3995 hz. The da}ta byte format is as follows: 0 2 4 6-- --- --- --- --- --- <---mark ! ! ! ! ! ! ! ! !} ! ! a ! ! 1 ! ! 3 ! ! 5 ! ! 7 ! --- --- --- --- --- <---spaceA = START BIT (SPACE0-7 = DATA BITS}B = STOP BIT (MARK)Record DefinitionRecords are 132 bytes long. A record is broken down in the following way: 2 marker }characters for speed measurement, a control byte, 128 data bytes, and a checksum byte. The record format is shown below:----}--------! O1O1O1O1 ! 1st marker------------ (For speed measurement)! O1O1O1O1 ! 2nd marker------------! control !! } byte !------------- 128 data -- bytes -------------! checksum !------------1st and 2nd MARKEREach marker chara}cter is a 55 (hex). Including start and stop bits, each marker is 1O bits long. Ideally, there should be no blank tape betwee }n the markers and the subsequent data.PAGE C-2 ABOVE marker is 1O bits long. Ideally, there should be no blank tape betwee70080Speed MeasurementThe purpose of the marker is to adjust the baud rate.The input baud rate is assumed to be a nomi }nal 6OO baud. This is adjusted, however, by the SIO routine to account for drive motor variations, stretched tape etc. Once t }he true baud rate is calculated, the hardware is adjusted accordingly. Input baud rates ranging from 318 to 14O7 baud can the }oretically be handled using this technique.The OS checks the tape speed in the following manner: the software looks at the p}okey serial-in bit continously. Looking for a start (O bit) which signifies the begginning of a record. When it finds one, th}e OS stores the current frame counter by saving the antic vcount (vertical screen counter). Continuing to look directly at th}e serial-in bit, the OS counts the 2O bits (end of the 2 markers), then uses VCOUNT and the frame counter to determine the el}apsed time. The baud rate to use is derived from the result. This is done for each record.Control byteThe control byte cont}ains one of three values:$FC indicates the record is a full data record (128 bytes).$FA indicates the record is a partially} full data record; fewer than 128 bytes were supplied by the user. This case may occur only in the record prior to the end-of}-file. The actual number of data bytes, 1 to 127, is stored in the last data byte prior to the checksum; i.e., the 128th data} byte.$FE indicates the record is an end-of-file record and is followed by 128 zero bytes.ChecksumThe checksum is generate}d and checked by the SIO routine, but is not contained in the cassette handler's I/O buffer CASBUF (O3FD).The checksum is a }single byte sum of all the other bytes in the record, including the two markers. The checksum is computed with end-around car}ry. As each byte is added into the sum, the carry bit is also added in.!--> partial sum! + data byte! + carry! -------}---------!!-<--resultPAGE C-3 ABOVEhe carry bit is also added in.!--> partial sum! + data byte! + carry! -------)0080TimingInter-record gapAs mentioned earlier, each record consists of 132 data bytes including the checksum byte. I}n order to distinguish one record from another, the cassette handler adds a pre-record write tone (PRWT) and post-record gap }(PRG). PRWT and PRG are both pure mark tone. The inter-record gap (IRG) between any two records thus consist of the PRG of th}e first record followed by the PRWT of the second record. The layout of the record and gaps is as follows:-----------------}-------------------------------------------! PRWT ! marker ! data ! PRG ! PRWT ! marker ! data ! PRG !---------------------}--------------------------------------- <--------record 1--------> <--------record 2-------->Normal IRG mode and short }IRG modeThe length of PRWT and PRG are dependent upon the write open mode. There are two types of IRG modes: normal IRG mode!} and short IRG mode.When a file is opened, the most significant bit of AUX2 specifies the mode. On subsequent output or inpu"}t, the cassette handler executes the read/write in either mode based on the MSB of the AUX2 byte: 7 O #} -----------------AUX2 !C! ! ! ! ! ! ! ! -----------------C = 1 indicates that the cassette is to be read/written in $}short IRG mode (continous mode).C = O indicates normal IRG mode.Normal IRG modeThis mode is used for a read interleaved w%}ith processing; i.e., the tape always comes to a stop after each record is read. If the computer "stops" the tape and gets it&}s processing done fast enough, the next read may occur so quickly that the cassette deck may see only a slight dip in the con'}trol line.Short IRG modeIn this mode the tape is not stoped between records, either when being written or during readback.(}On readback, the program must issue a read for each record before it passes the read head. The only common use of this mode s)}o far is storage of basic programs in internal (tokenized) form where, on readback, basic has nothing more to do with the dat*}a than put it in RAM. The special basic commands "CSAVE" and "CLOAD" specify this mode.PAGE C-4 ABOVEre to do with the dath0080There can be a potential problem with this. The software that writes the tape must allow long enough gaps, so the b,}egginning of records are not missed on readback.Timing structureThe timings for each of the inter-record gaps are as follow-}s:NORMAL IRG PRWT = 3 seconds of mark tone.SHORT IRG PRWT = O.25 seconds of mark tone.NORMAL IRG PRG = up to 1 second of.} unknown tones.SHORT IRG PRG = from O to n seconds of unknown tones, where n is dependant upon user program timing.Each r/}ecord is written with the following timing: once the motor starts and the PRWT is written, the duration of the tone depends o0}n the above format. The record follows, then the PRG is written. The motor is then stopped for normal mode, but continues wri1}ting mark for short IRG mode.Note that for the normal IRG mode, the tape will contain a section of unknown data because of s2}topping and restarting the motor. (up to 1 second of travel is possible, depending on the cassette macHIne.) this unknown dat3}a may be garbage data left previously on the tape.Noisy I/O featureThe noisy I/O feature is useful for determining the succ4}ess os reading the tape, particularly with CLOAD. Marks and spaces use different sound frequencies and you quickly learn the 5}good and the bad sounds the OS makes.File StructureA file consists of the following three elements:o A 2O-second leader of6} the mark toneo Any number of data recordso End-of-fileWhen the file is opened (output), the OS starts by writing a mark l7}eader of 2O seconds, the OS then returns to the caller, but leaves the tape running and writing marks.The write/read timeout8} counter is set for about 35 seconds as the OS returns. If the timeout occurs before the first record is written, the tape wi9}ll stop, leaving a gap between the open leader and the first record leader.PAGE C-5 ABOVEst record is written, the tape wi\0080Tape structureThere are two sides to each tape. Each side has two tracks, one for audio and the other for one for ;}digital recording. This way the tape can be recorded in both directions. Following is a flat view of the tape: -----<}------------- ! audio track ! left track ------------------side a ------------------ ! digital t=}rack ! right track --------------------------------------------------------- ------------------ ! d>}igital track ! right track ------------------side b ------------------ ! audio track ! left track ?} ------------------Tapes are recorded in 1/4 track stereo format at 1 7/8 inches per second (ips). Note that the atari 8OO@} computers utilizes a tape deck that has a stereo head configuration (not single or mono type).Cassette bootThe cassette boA}ot program can be booted from the cassette at power-up time as part of the system initialization. System initialization perfoB}rms functions such as zeroing all of the hardware registers, clearing RAM, setting flags and so on.After all the resident haC}ndlers are brought in, if the [start] key is pressed, the cassette boot request flag CKEY [OO4A] is set. If the cassette bootD} request flag is set, then a cassette boot operation is attempted.The following requirements must be met in order to boot frE}om the cassette:1. The operator must press the [start] key as power is applied to the system.2. A cassette tape with a propF}er boot format file must be installed in the cassette drive, and the [play] button on the recorder must be pressed.PAGE C-6G} ABOVE format file must be installed in the cassette drive, and the [play] button on the recorder must be pressed.PAGE C-600803. The cassette file must have been created in short IRG mode.4. When the audio prompt occurs, the the operator muI}st press a key on the keyboard.If all of these conditions are met, the OS will read the boot file from the cassette and thenJ} transfer control to the software that was read in. The cassette boot process is given in more detail below:---------------K}---! !! ignored ! 1st byte! !------------------! !! # of rL}ecords !! !------------------! !! memory address ! lo! !----- ---M}---! !! to start load ! HI! !------------------! !! init ! N}lo! !----- ------! !! address ! HI 6th byte! !----------O}--------1st BYTE is not used by the cassette boot process.2nd byte contains the number of 128 byte cassette records to be rP}ead as part of the boot process (including the record containing this information). This number may range from 1 to 255, withQ} O meaning 256.3rd and 4th bytes contain the address (LO,HI) at wHIch to start loading the first byte of the file.5th and 6R}th bytes contain the address (LO,HI) to wHIch control is transferred after the boot process is complete. Pressing the [s/reseS}t] key will also transfer control to this address assuming that the boot process is complete.When step 2 is complete, the caT}ssette boot program will have:o Saved number of records to booto Saved the load addresso Saved the initialization addreU}ss in CASINI [O2,O3]PAGE C-7 ABOVEed number of records to booto Saved the load addresso Saved the initialization addre%00803. Move the record just read to the load address specified.4. Read the remaining records directly to the load areaW}.5. JSR to the load address +6 where a miltistage boot process may continue. The carry bit will indicate the success of the X}operation (carry set = error, carry reset = success) on return.6. JSR indirectly through casini for initialization of the apY}plication. The application should put its starting address into dosvec [0a,0b] during initialization, and then return.7. JMPZ} indirectly through DOSVEC to transfer control to the application.Pressing the [S/RESET] key after the application is fully [}booted will cause steps 6 and 7 to repeat.PAGE C-8 ABOVEcation.Pressing the [S/RESET] key after the application is fully ;0080CASSETTE APPLICATIONSHOW TO CONFIGURE THE CASSETTE SYSTEMMost serial bus devices have two identical connectors: ]}one is a serial bus input and the other a serial bus extender. Using these connectors, peripherals may be "daisychained" simp^}ly by cabling them together in a sequential fashion like the following diagram:------! tv ! serial bus connector------_} ! ! ! ! ------- ------- --------- ! ! ! ! ! ! ! ! ! ! `} ! ! ! !------- --------- --------- -------! 800 ! ! disk ! ! disk ! ! 410 !------- ! drive ! a}! drive ! ------- --------- --------- Figure C-1 daisychained equipmentHowever, the cassette does not conformb} to the protocol of the other peripherals that use the serial bus. The cassette must be the last device on the serial bus becc}ause it does not have a serial bus extender connector as the other peripherals do. The lack of a bus extender assures that thd}ere is never more than one cassette drive connected to the system. The system cannot sense the absence or presence of the case}sette drive, so it may be connected and disconnected at will.Whenever there is a need to open a cassette file for reading orf} writing, use the following instructions: Input (data from 410 to 800) when the cassette is opened for input, a single audig}ble tone is generated using the keyboard speaker. If the cassette is ready(power on, serial bus cable connected, tape cued toh} start file), the user must depress [play] button on the cassette and any atari 800 key (except [break]) to initiate tape reai}ding. Output (data from 800 to 410) when the cassette is opened for output, two separate audible tones are generated using j}the keyboard speaker. If the cassette is ready (as previously described), the user must simultaneously press the [play] and [k}record] buttons on the cassette, and then press any keyboard key (except [break]) to initiate writing the tape.PAGE C-9 ABOl}VEord] buttons on the cassette, and then press any keyboard key (except [break]) to initiate writing the tape.PAGE C-9 ABO0080SAVING AND LOADING DIGITAL PROGRAMSConceptThe following technique saves the digital data directly from the computn}er through its I/O port of either the atari 410 program recorder or the atari lab machine which uses 1/4 inch tape recorded ao}t 7 1/2 inches per second.FOR BASICFormat: CSAVE 100 CSAVEThis command is usually used in direct mode to save a rap}m-resident program onto cassette tape. CSAVE writes the tokenized version of the program to the 410.Format: CLOAD 10q}0 CLOADThis command can be used in either direct or deferred mode to read programs from cassette tape into ram for executionr}.FOR ASSEMBLY LANGUAGESource ProgramFormat: LIST#C:[,XX,YY]This command is used to write assembly source code. The items s}in the optional brackets [,XX,YY] mean to transfer only lines XX to YY to cassette. If line numbers are not provided, the whot}le program is listed to cassette.Format: ENTER#C:This command reads source code from the cassette.Object ProgramFormat: Su}AVE#C! interim !->! work !R ! master ! ! master ! ! master !I ---------- ----------- ---------- } ! ------------------- !MASS PRODUCTION OF CASSETTESINTERIM MASTER is reco}mended for the duplicator, because the work master may be destroyed or worn from excessive use. The source master should be r}eserved only for emergency need. The INTERIM MASTER is the backup copy for the work master.Mass Production of CassettesAt p}resent, atari prefers the bin loop method for mass production: the work master is copied to produce a loop master. The loop m}aster may be on 1/4 inch, or any tape width. The bin loop is spliced into a continuous loop with a short clear leader at the }splice. It is placed in a high-speed loop master machine which has one or more slave machines. The configuration is shown in }figure C-4PAGE C-16 ABOVEgh-speed loop master machine which has one or more slave machines. The configuration is shown in 0080 master machine slave machines ------ ------ ------ ------read !O O! !O O! !O O! !}O O!head-->[] !====! [] !==! [] !==! [] ! ------ ------ ------ ---------------------! ! ! !! ! } O)!! ! -------- !! ! (O !! ! -------- !! ! O)<-----loop master! ! -------- !! ! (O !! ! --}------ !! ! O)!! ! -------- !! ! (O !! ! -------- !! (O O)!! ---------- !--------------- } Figure C-4The loop master is repeatedly read. If the duplicator wants to produce 100 cassettes, for example, the le}ngth of the tape on the slave machine is measured to the length of the program multiplied by 100. There is a counter on the m}aster machine and it is set to 100.As the loop master is continuously read, the data (all four tracks) is copied onto the sl}ave machine tape.As the clear section in the loop master is sensed, the master machine produces a cutting tone which is reco}rded on one or more tracks on the slave machine tapes. The counter will then increase by one.Each finished tape from the sla}ve machine has 100 recorded programs with 100 cutting tones recorded. It is fed into an automatic loading machine which winds} the tape into C-Zero cassette shells. The configuration is like this: loader ----------}----------- ! ** ** ! ! '* * * *' !tape from ! '** **' !sl}ave machine ! ' --------- ' ! ! '! !' ! ! ! O O ! ! ! } --------- ! ! ! ----------------------O = cassette tape hubs- = cas}sette shell Fugure C-5PAGE C-17 ABOVE! ----------------------O = cassette tape hubs- = cas80080The cassette shells come with a small loop of leader which is bound to the cassette tape hubs. The loader pulls the} eader from the shell, cuts it, and splices the end of the slave machine tape to the leader. The tape hub is used to wind the} tape into the shell until the cutting tone is sensed. The slave machine tape is then cut and spliced to the leader on the ot}her hub.The cassette shell is removed either manually or mechanically from the loader and the tape in the cassette shell is} fully wound. The next cassette shell is loaded by the same process.Quality Control TestingAny time that a production run i}s created, samples must be taken from it and verified before it is approved and released.The QC testing is done normally by }taking the first and the last cassette produced. Atari must receive at least 10 samples from each master released.PAGE C-18} ABOVEthe first and the last cassette produced. Atari must receive at least 10 samples from each master released.PAGE C-180080APPENDIX DTELEVISION ARTIFACTSThis section discusses how to get multiple colors out of a single color graphics }mode through the use of television artifacts.The antic modes with which this can be accomplished are 2,3, and 15 antic mode }2 corresponds to basic mode 0, antic mode 15 is a basic mode 8, and antic mode 3 has no corresponding basic mode. Each of the}se modes has a pixel resolution of one half color clock by one scan line. They are generally considered to have one color and} two luminances. With the use of artifacts, pixels of four different colors can be displayed on the screen in each of these m}odes.The term tv artifacts refers to a spot or "pixel" on the screen that displays a different color than the one assigned t}o it.A simple example of artifacts using the atari computer is shown by entering the following lines:GRAPHICS 8COLOR 1POK}E 710,0PLOT 60,60PLOT 63,60These statements will plot two points on a black background; however each pixel will have a dif}ferent color.To understand the cause of these differing colors one must first understand that all the display information fo}r the television display is contained in a modulated television signal.The two major components of this signal are the lumin}ance, or brightness, and the color, or tint. The luminance information is the primary signal, containing not only the brightn}ess data but also the horizontal and vertical sync and blanks. The color signal contains the color information and is combine}d or modulated into the luminance waveform.The luminance of a pixel on the screen is directly dependent on the amplitude of }the signal at that point. The higher the amplitude of the signal, the brighter the pixel.The color information, however, is }a phase shifted signal. A phase-shifted signal is a constanly oscillating waveform that has been delayed by some amount of ti}me relative to a reference signal, and this time delay is translated into the color.The color signal oscillates at a constan}t rate of about 3.579 MHz, thus defining the highest horizonal color resolution of a television set.This appears on the scree}n in the form of 160 visible color cycles across one scan line. (There are actully 228 color cycles including the horizontal }blank and sync, and any overscan.)PAGE D-1 ABOVEe scan line. (There are actully 228 color cycles including the horizontal 3